home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / security / doc / clippings / 920214-01 < prev    next >
Encoding:
Internet Message Format  |  1992-03-20  |  5.4 KB
  1. From: rivest@theory.lcs.mit.edu (Ron Rivest)
  2. Newsgroups: alt.security
  3. Subject: Semi-variable passwords for remote login
  4. Date: 14 Feb 92 00:01:21 GMT
  5. Distribution: alt.security
  6. Organization: MIT Lab for Computer Science
  7.  
  8.  
  9.  
  10.     SEMI-VARIABLE PASSWORDS FOR REMOTE LOGIN -- A PROPOSAL
  11.     ------------------------------------------------------
  12.             Ronald L. Rivest
  13.         MIT Laboratory for Computer Science
  14.             2/13/92
  15.  
  16. Passwords are a notorious security weakness.  Either they are poorly
  17. chosen, in which case they are easily found, or else they are
  18. well-chosen, hard to remember, and then often written down (and then lost or
  19. disclosed).  And in any case, a fixed password can easily be
  20. compromised when transmitted over the net.  I think it is time to
  21. recognize that ``static (fixed) passwords are not sufficient for
  22. security when network logins are allowed'' and to ACT on that knowledge.
  23.  
  24. Here is a proposal for password usage and checking that is intended to
  25. be practical, yet quite secure.  I would like to see it implemented here
  26. at MIT in our ``Theory Group'' network of SUNs, but this has not been done yet.
  27.  
  28. The summary of the proposal: Each user maintains both a ``static
  29. password'' (which he remembers), and a list of one-time ``variable
  30. passwords'' (which he has on a sheet of paper).  For a local login
  31. (at the machine console), only the static password is needed.  For a
  32. remote login (over the net) the password he uses is the
  33. concatenation of his static password and the next unused variable
  34. password on his variable-password list.
  35.  
  36. DISCUSSION:
  37. - -----------
  38.  
  39. (1) It is assumed that it local logins can be distinguished from remote logins.
  40.  
  41. (2) A sample one-time password-list is obtainable by anonymous ftp from
  42.     theory.lcs.mit.edu, in the file pub/rivest/passwords/password-list.ps
  43.     This is a sample postscript file giving 150 one-time passwords, plus
  44.     instructions on their use.  It is designed to fold up nicely and fit
  45.     in a wallet, without losing passwords in the fold creases.
  46.  
  47. (3) If a user loses his password list, not all is lost, since his static
  48.     password is not thereby compromised.  Similarly, loss of a static
  49.     password by itself is not sufficient to allow an adversary to log in
  50.     over the network.  
  51.  
  52. (4) A user's variable password list should expire after a certain amount of 
  53.     time (say three to six months), and be re-issued by the system security 
  54.     administrator with new passwords.
  55.  
  56. (5) Since the variable passwords are not needed for local logins, most logins
  57.     would not change for our users.  Only remote logins would require this
  58.     additional authentication information.  Users will presumably understand
  59.     and sympathize the requirement that remote logins need additional 
  60.     authentication.  However, ``inner loop'' (a local login) is as easy
  61.     as it always was for the user.
  62.  
  63. (6) The basic format of the login protocol is unchanged: you must type a
  64.     login id and a password.  This may have advantages for applications 
  65.     exercise a login protocol.  
  66.  
  67. (7) The user is not required to purchase any additional hardware.  (A 
  68.     fancy version of this general approach would be to use a Security
  69.     Dynamics SecurID card, which displays a continually varying password.
  70.     This may be better if you can afford it, but it some expensive for
  71.     our environment.)
  72.  
  73. (8) If desired for some reason, some users might  have zero-length
  74.     variable passwords---in effect, they just have the usual static password.
  75.     That is, the use of variable passwords could be chosen on a per-user
  76.     basis.  However, this obviously negates much of the benefit of the whole 
  77.     idea...
  78.  
  79. (9) The password checking program needs to keep track of the variable 
  80.     password list for each user, and to know which variable passwords he's
  81.     already used.  We envision dedicating a machine to just this function
  82.     (say, a small PC on our Ether sub-net).  This machine could ONLY be
  83.     logged into through the console.  It would, however, be queried by the
  84.     login protocols of the other machines to check passwords.  The password
  85.     lists are stored only on the dedicated PC.  The password-checking PC
  86.     might be queried by a remote procedure call, which would return
  87.     "OK" or "not-OK" for a proposed remote userid-password combination.
  88.     There are probably other good ways of implementing this function;
  89.     obviously the integrity and security of the password databases is critical.
  90.     A separate machine means that the files will not be compromised even
  91.     if someone breaks in somehow.  
  92.  
  93. (10) The dedicated PC would be capable of creating new password lists
  94.      and printing them out securely.  
  95.  
  96. (11) The storage requirements for the password lists on the dedicated
  97.      machine are very manageable: if you have 1000 users with 150 5-byte
  98.      passwords each, you need only 750,000 bytes of storage.
  99.  
  100. (12) If a typical user logs in remotely at most twice a day, then a 150-
  101.      password list should last him for 2-3 months.
  102.  
  103. (13) The use of printed variable password lists permits them to be mailed
  104.      out to users who never stop by in person.  They can even be faxed
  105.      in an emergency.
  106.  
  107. - --------
  108.  
  109. I would appreciate any comments or suggestions people have about this
  110. scheme.  (Post to the alt.security, rather than mailing it to me...)  
  111. Are there any obvious security problems, human-engineering problems, or 
  112. other difficulties?  Is there anything better that's just as easy to do?
  113. Comments?
  114.  
  115. ------- End of Forwarded Message
  116.  
  117.  
  118.  
  119.